Dynomotion

Group: DynoMotion Message: 2229 From: himykabibble Date: 11/14/2011
Subject: v428x & G52
Tom,

I see you've at least started adding G52 in v428x. Is that working properly, as far as you know?

Regards,
Ray L.
Group: DynoMotion Message: 2230 From: himykabibble Date: 11/14/2011
Subject: Re: v428x & G52
Hmmmm.... After trying it, I think it's not... If I do the following:

G0 Z-1.0 => Z DRO reads -1.0
G92 Z0 => Z DRO reads 0.0
G0 Z-1.0 => Z DRO reads -1.0
G52 Z-1.0 => Z DRO SHOULD change to 0.0, but it remains at -1.0
G52 Z0.0 => Z DRO should return to -1.0

Regards,
Ray L.

--- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@...> wrote:
>
> Tom,
>
> I see you've at least started adding G52 in v428x. Is that working properly, as far as you know?
>
> Regards,
> Ray L.
>
Group: DynoMotion Message: 2239 From: Tom Kerekes Date: 11/14/2011
Subject: Re: v428x & G52
Hi Ray,
 
That is doing as we intended, maybe we misunderstood the G52 definition:
 
But you didn't state the starting conditions or the final result.  But I'll assume all offsets were zero from the start:
 
Assume: Interpreter coords(DRO)  0 +  Offset 0  = Machine Coords 0
 
G0 Z-1.0 => Z DRO reads -1.0
    This should cause a physical motion of -1 inches and the result will now be
    Interpreter coords  -1  +  Offset 0  = Machine Coords -1
 
G92 Z0 => Z DRO reads 0.0
    Computes offset of -1 so that Machine remains the same with DRO 0
    Interpreter coords  0  +  Offset -1  = Machine Coords -1
 
G0 Z-1.0 => Z DRO reads -1.0
    This should cause a physical motion of -1 inches and the result will now be
    Interpreter coords  -1  +  Offset -1  = Machine Coords -2
 
G52 Z-1.0 => Z DRO SHOULD change to 0.0, but it remains at -1.0
    This forces the offset to -1 but it is aleady so changes nothing
 
G52 Z0.0 => Z DRO should return to -1.0 (what happened??)
    Forcing the offset to zero should make DRO match Machine coordinates -2
    Interpreter coords  -2  +  Offset 0  = Machine Coords -2

 
Regards
TK
 
 

Group: DynoMotion Message: 2241 From: himykabibble Date: 11/14/2011
Subject: Re: v428x & G52
Tom,

First, I am no expert on this, but I do know how G92 and G52 work in Mach3, which is, in theory, consistent with the Fanuc implementation, and with the explanations in Peter Smid's book. Based on that, I believe both G92 and G52 are broken in v428x (at least - I never checked the G92 behavior in v426). Here is one sequence that I believe is wrong:

First, I won't spell it out each time, but let's assume we always start these examples by doing a G52 Z0.0, then homing, so when we execute each block of code below, we start with work zero == machine zero, and G52 and G92 offsets are all zero. Then do:

G92 Z2.0 => Z DRO should show +2.0
G52 Z0.0 => This should have no effect, but it sets Z DRO to 0.0, REMOVING the G92 offset.

The G52, should do nothing, since we started by clearing the G52 offset before homing the machine. But, what it appears to be doing is clearing the G92 offset!

Here's another example:

G52 Z-1.0 => Z DRO should show +1.0
G92 Z0.0 => Z DRO should show 0.0
G52 Z0.0 => Z DRO should show -1.0, but instead remains at 0.0

Here's a final example:

G92 Z2.0 => Z DRO should show +2.0
G52 Z-0.5 => Z DRO should show +2.5
G52 Z0.0 => Z DRO should show +2.0

Here is my understanding of how it should be:

G92 is used to tell the controller what work coordinates you WANT the current position to be. The controller calculates the necessary G92 offset to apply, to make the work coordinates what you asked for. So, for example: G92 Z0.0, will always make the current Z axis position 0.000.

G52 applies a temporary *additional* offset, which is expressed as a relative offset from any existing G92 offset. So, for example, if I do a G52 Z-1.0, the Z DRO should shift from its current value by +1.0. I find the easiest way to think of this is in terms of what happens to the axis work zero position. G52 Z-1.0 says: Shift the Z axis work zero DOWN by 1". So, if we were at Z=0.0 before the G52, we'll be at Z+1.0 after a G52 Z-1.0. If I now want to return to where I was, I simply execute a G52 Z0.0, and I return to the pre-existing G92 offsets.

The G92 and G52 offsets are additive, but separate.

It appears to me that when I do a G52 with KMotionCNC, it is clobbering the G92 offsets, which is wrong. G52 Z0.0 should remove ONLY the offset, if any, that was applied with another G52, without affecting any offset that was applied with G92. If no G52 offset is in effect, then G52 Z0.0 should have no effect whatsoever. In fact, when you use G52, it is good practice to start any program by zeroing the G52 offsets for all axes, in case an offset was left in effect from a previous run.

At least that's my understanding, and how I've always used it with Mach3....

Regards,
Ray L.

--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> Hi Ray,
>  
> That is doing as we intended, maybe we misunderstood the G52 definition:
>  
> But you didn't state the starting conditions or the final result.  But I'll assume all offsets were zero from the start:
>  
> Assume: Interpreter coords(DRO)  0 +  Offset 0  = Machine Coords 0
>  
> G0 Z-1.0 => Z DRO reads -1.0
>     This should cause a physical motion of -1 inches and the result will now be    Interpreter coords  -1  +  Offset 0  = Machine Coords -1
>  
>     Interpreter coords  0  +  Offset -1  = Machine Coords -1
>  
> G0 Z-1.0 => Z DRO reads -1.0
>     This should cause a physical motion of -1 inches and the result will now be
>  
> G52 Z-1.0 => Z DRO SHOULD change to 0.0, but it remains at -1.0
>     This forces the offset to -1 but it is aleady so changes nothing
>  
> G52 Z0.0 => Z DRO should return to -1.0 (what happened??)
>     Forcing the offset to zero should make DRO match Machine coordinates -2
>     Interpreter coords  -2  +  Offset 0  = Machine Coords -2
> Regards
> TK
>  
>  
>
> From: himykabibble <jagboy@...>
> To: DynoMotion@yahoogroups.com
> Sent: Monday, November 14, 2011 9:19 AM
> Subject: [DynoMotion] Re: v428x & G52
>
>
>  
> Hmmmm.... After trying it, I think it's not... If I do the following:
>
> G0 Z-1.0 => Z DRO reads -1.0
> G92 Z0 => Z DRO reads 0.0
> G0 Z-1.0 => Z DRO reads -1.0
> G52 Z-1.0 => Z DRO SHOULD change to 0.0, but it remains at -1.0
> G52 Z0.0 => Z DRO should return to -1.0
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@> wrote:
> >
> > Tom,
> >
> > I see you've at least started adding G52 in v428x. Is that working properly, as far as you know?
> >
> > Regards,
> > Ray L.
> >
>
>
>
>
>
>
>      Interpreter coords  -1  +  Offset -1  = Machine Coords -2 G92 Z0 => Z DRO reads 0.0
>     Computes offset of -1 so that Machine remains the same with DRO 0
>
Group: DynoMotion Message: 2242 From: Tom Kerekes Date: 11/14/2011
Subject: Re: v428x & G52
Hi Ray,
 
Well that is the issue.  I'm assuming that G92 and G52 are supposed affect the *same* offset (referred to a Axis Offsets in the source code). 
 
I looked up a reference of how EMC handles it and that's what it said. 
 
Also here is a reference from tormach which I thought was Mach3 based.
 
 
 
And here is the Mach3 on-line help
 
To offset the current point by a given positive or negative distance (without motion), program
 G52 X~ Y~ Z~ A~ B~ C~ , where the axis words contain the offsets you want to provide. All axis words are optional, except that at least one must be used. If an axis word is not used for a given axis, the coordinate on that axis of the current point is not changed. It is an error if:
¨    all axis words are omitted.
G52 and G92 use common internal mechanisms in Mach3 and may not be used together.
When G52 is executed, the origin of the currently active coordinate system moves by the values given.
The effect of G52 is cancelled by programming G52 X0 Y0 etc.
Here is an example. Suppose the current point is at X=4 in the currently specified coordinate system, then G52 X7 sets the X-axis offset to 7, and so causes the X-coordinate of the current point to be -3.
The axis offsets are always used when motion is specified in absolute distance mode using any of the fixture coordinate systems.  Thus all fixture coordinate systems are affected by G52.
 
I haven't tried it in Mach3 though :}
 
TK
 

Group: DynoMotion Message: 2243 From: himykabibble Date: 11/14/2011
Subject: Re: v428x & G52
Tom,

Like I said, I'm no expert, but Mach3 (current version, and at least several previous versions) work as I outlined. I'm going to ping some G-code experts I know, and see what they have to say. I have an old version of Mach3 that works, near as I can tell, like KMotionCNC is now working, so I'm more confused than ever at this point.

Regards,
Ray L.

--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> Hi Ray,
>  
> Well that is the issue.  I'm assuming that G92 and G52 are supposed affect the *same* offset (referred to a Axis Offsets in the source code). 
>  
> I looked up a reference of how EMC handles it and that's what it said. 
>  
> Also here is a reference from tormach which I thought was Mach3 based.
>  
> http://www.tormach.com/g52.html
>  
>  
> And here is the Mach3 on-line help
>  
> G52 Coordinate System Offset
> I haven't tried it in Mach3 though :}
>  
> TK
>  
>
> From: himykabibble <jagboy@...>
> To: DynoMotion@yahoogroups.com
> Sent: Monday, November 14, 2011 5:59 PM
> Subject: [DynoMotion] Re: v428x & G52
>
>
>  
> Tom,
>
> First, I am no expert on this, but I do know how G92 and G52 work in Mach3, which is, in theory, consistent with the Fanuc implementation, and with the explanations in Peter Smid's book. Based on that, I believe both G92 and G52 are broken in v428x (at least - I never checked the G92 behavior in v426). Here is one sequence that I believe is wrong:
>
> First, I won't spell it out each time, but let's assume we always start these examples by doing a G52 Z0.0, then homing, so when we execute each block of code below, we start with work zero == machine zero, and G52 and G92 offsets are all zero. Then do:
>
> G92 Z2.0 => Z DRO should show +2.0
> G52 Z0.0 => This should have no effect, but it sets Z DRO to 0.0, REMOVING the G92 offset.
>
> The G52, should do nothing, since we started by clearing the G52 offset before homing the machine. But, what it appears to be doing is clearing the G92 offset!
>
> Here's another example:
>
> G52 Z-1.0 => Z DRO should show +1.0
> G92 Z0.0 => Z DRO should show 0.0
> G52 Z0.0 => Z DRO should show -1.0, but instead remains at 0.0
>
> Here's a final example:
>
> G92 Z2.0 => Z DRO should show +2.0
> G52 Z-0.5 => Z DRO should show +2.5
> G52 Z0.0 => Z DRO should show +2.0
>
> Here is my understanding of how it should be:
>
> G92 is used to tell the controller what work coordinates you WANT the current position to be. The controller calculates the necessary G92 offset to apply, to make the work coordinates what you asked for. So, for example: G92 Z0.0, will always make the current Z axis position 0.000.
>
> G52 applies a temporary *additional* offset, which is expressed as a relative offset from any existing G92 offset. So, for example, if I do a G52 Z-1.0, the Z DRO should shift from its current value by +1.0. I find the easiest way to think of this is in terms of what happens to the axis work zero position. G52 Z-1.0 says: Shift the Z axis work zero DOWN by 1". So, if we were at Z=0.0 before the G52, we'll be at Z+1.0 after a G52 Z-1.0. If I now want to return to where I was, I simply execute a G52 Z0.0, and I return to the pre-existing G92 offsets.
>
> The G92 and G52 offsets are additive, but separate.
>
> It appears to me that when I do a G52 with KMotionCNC, it is clobbering the G92 offsets, which is wrong. G52 Z0.0 should remove ONLY the offset, if any, that was applied with another G52, without affecting any offset that was applied with G92. If no G52 offset is in effect, then G52 Z0.0 should have no effect whatsoever. In fact, when you use G52, it is good practice to start any program by zeroing the G52 offsets for all axes, in case an offset was left in effect from a previous run.
>
> At least that's my understanding, and how I've always used it with Mach3....
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> >
> > Hi Ray,
> >  
> > That is doing as we intended, maybe we misunderstood the G52 definition:
> >  
> > But you didn't state the starting conditions or the final result.  But I'll assume all offsets were zero from the start:
> >  
> > Assume: Interpreter coords(DRO)  0 +  Offset 0  = Machine Coords 0
> >  
> > G0 Z-1.0 => Z DRO reads -1.0
> >     This should cause a physical motion of -1 inches and the result will now be    Interpreter coords  -1  +  Offset 0  = Machine Coords -1
> >  
> >     Interpreter coords  0  +  Offset -1  = Machine Coords -1
> >  
> > G0 Z-1.0 => Z DRO reads -1.0
> >     This should cause a physical motion of -1 inches and the result will now be
> >  
> > G52 Z-1.0 => Z DRO SHOULD change to 0.0, but it remains at -1.0
> >     This forces the offset to -1 but it is aleady so changes nothing
> >  
> > G52 Z0.0 => Z DRO should return to -1.0 (what happened??)
> >     Forcing the offset to zero should make DRO match Machine coordinates -2
> >     Interpreter coords  -2  +  Offset 0  = Machine Coords -2
> > Regards
> > TK
> >  
> >  
> >
> > From: himykabibble <jagboy@>
> > To: DynoMotion@yahoogroups.com
> > Sent: Monday, November 14, 2011 9:19 AM
> > Subject: [DynoMotion] Re: v428x & G52
> >
> >
> >  
> > Hmmmm.... After trying it, I think it's not... If I do the following:
> >
> > G0 Z-1.0 => Z DRO reads -1.0
> > G92 Z0 => Z DRO reads 0.0
> > G0 Z-1.0 => Z DRO reads -1.0
> > G52 Z-1.0 => Z DRO SHOULD change to 0.0, but it remains at -1.0
> > G52 Z0.0 => Z DRO should return to -1.0
> >
> > Regards,
> > Ray L.
> >
> > --- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@> wrote:
> > >
> > > Tom,
> > >
> > > I see you've at least started adding G52 in v428x. Is that working properly, as far as you know?
> > >
> > > Regards,
> > > Ray L.
> > >
> >
> >
> >
> >
> >
> >
> >      Interpreter coords  -1  +  Offset -1  = Machine Coords -2 G92 Z0 => Z DRO reads 0.0
> >     Computes offset of -1 so that Machine remains the same with DRO 0
> >
>
>
>
>
>
> To offset the current point by a given positive or negative distance (without motion), program
>  G52 X~ Y~ Z~ A~ B~ C~, where the axis words contain the offsets you want to provide. All axis words are optional, except that at least one must be used. If an axis word is not used for a given axis, the coordinate on that axis of the current point is not changed. It is an error if:
> ¨    all axis words are omitted.
> G52 and G92 use common internal mechanisms in Mach3 and may not be used together.
> When G52 is executed, the origin of the currently active coordinate system moves by the values given.
> The effect of G52 is cancelled by programming G52 X0 Y0etc.
> Here is an example. Suppose the current point is at X=4 in the currently specified coordinate system, then G52 X7sets the X-axis offset to 7, and so causes the X-coordinate of the current point to be -3.
> The axis offsets are always used when motion is specified in absolute distance mode using any of the fixture coordinate systems.  Thus all fixture coordinate systems are affected by G52.
>
Group: DynoMotion Message: 2244 From: Tom Kerekes Date: 11/14/2011
Subject: Re: v428x & G52
Hi Ray,
 
Yes I just tried Mach3 and it works like those references I sent.  In fact you can look on the Diagnostics screen and see there is only one offset G92 and it changes when you do G52.
 
Regards
TK

Group: DynoMotion Message: 2245 From: himykabibble Date: 11/14/2011
Subject: Re: v428x & G52
Tom,

I think I'm finally starting to grok this, and I think you're right. What I can't figure out is how I got away with what I've been doing the last few months. I do now think G53 can only be used in conjunction with G54-G59, and really should not be used together with G92, at least not without using great care.

Regards,
Ray L.

--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> Hi Ray,
>  
> Yes I just tried Mach3 and it works like those references I sent.  In fact you can look on the Diagnostics screen and see there is only one offset G92 and it changes when you do G52.
>  
> Regards
> TK
>
> From: himykabibble <jagboy@...>
> To: DynoMotion@yahoogroups.com
> Sent: Monday, November 14, 2011 7:39 PM
> Subject: [DynoMotion] Re: v428x & G52
>
>
>  
> Tom,
>
> Like I said, I'm no expert, but Mach3 (current version, and at least several previous versions) work as I outlined. I'm going to ping some G-code experts I know, and see what they have to say. I have an old version of Mach3 that works, near as I can tell, like KMotionCNC is now working, so I'm more confused than ever at this point.
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> >
> > Hi Ray,
> >  
> > Well that is the issue.  I'm assuming that G92 and G52 are supposed affect the *same* offset (referred to a Axis Offsets in the source code). 
> >  
> > I looked up a reference of how EMC handles it and that's what it said. 
> >  
> > Also here is a reference from tormach which I thought was Mach3 based.
> >  
> > http://www.tormach.com/g52.html
> >  
> >  
> > And here is the Mach3 on-line help
> >  
> > G52 Coordinate System Offset
> > I haven't tried it in Mach3 though :}
> >  
> > TK
> >  
> >
> > From: himykabibble <jagboy@>
> > To: DynoMotion@yahoogroups.com
> > Sent: Monday, November 14, 2011 5:59 PM
> > Subject: [DynoMotion] Re: v428x & G52
> >
> >
> >  
> > Tom,
> >
> > First, I am no expert on this, but I do know how G92 and G52 work in Mach3, which is, in theory, consistent with the Fanuc implementation, and with the explanations in Peter Smid's book. Based on that, I believe both G92 and G52 are broken in v428x (at least - I never checked the G92 behavior in v426). Here is one sequence that I believe is wrong:
> >
> > First, I won't spell it out each time, but let's assume we always start these examples by doing a G52 Z0.0, then homing, so when we execute each block of code below, we start with work zero == machine zero, and G52 and G92 offsets are all zero. Then do:
> >
> > G92 Z2.0 => Z DRO should show +2.0
> > G52 Z0.0 => This should have no effect, but it sets Z DRO to 0.0, REMOVING the G92 offset.
> >
> > The G52, should do nothing, since we started by clearing the G52 offset before homing the machine. But, what it appears to be doing is clearing the G92 offset!
> >
> > Here's another example:
> >
> > G52 Z-1.0 => Z DRO should show +1.0
> > G92 Z0.0 => Z DRO should show 0.0
> > G52 Z0.0 => Z DRO should show -1.0, but instead remains at 0.0
> >
> > Here's a final example:
> >
> > G92 Z2.0 => Z DRO should show +2.0
> > G52 Z-0.5 => Z DRO should show +2.5
> > G52 Z0.0 => Z DRO should show +2.0
> >
> > Here is my understanding of how it should be:
> >
> > G92 is used to tell the controller what work coordinates you WANT the current position to be. The controller calculates the necessary G92 offset to apply, to make the work coordinates what you asked for. So, for example: G92 Z0.0, will always make the current Z axis position 0.000.
> >
> > G52 applies a temporary *additional* offset, which is expressed as a relative offset from any existing G92 offset. So, for example, if I do a G52 Z-1.0, the Z DRO should shift from its current value by +1.0. I find the easiest way to think of this is in terms of what happens to the axis work zero position. G52 Z-1.0 says: Shift the Z axis work zero DOWN by 1". So, if we were at Z=0.0 before the G52, we'll be at Z+1.0 after a G52 Z-1.0. If I now want to return to where I was, I simply execute a G52 Z0.0, and I return to the pre-existing G92 offsets.
> >
> > The G92 and G52 offsets are additive, but separate.
> >
> > It appears to me that when I do a G52 with KMotionCNC, it is clobbering the G92 offsets, which is wrong. G52 Z0.0 should remove ONLY the offset, if any, that was applied with another G52, without affecting any offset that was applied with G92. If no G52 offset is in effect, then G52 Z0.0 should have no effect whatsoever. In fact, when you use G52, it is good practice to start any program by zeroing the G52 offsets for all axes, in case an offset was left in effect from a previous run.
> >
> > At least that's my understanding, and how I've always used it with Mach3....
> >
> > Regards,
> > Ray L.
> >
> > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > >
> > > Hi Ray,
> > >  
> > > That is doing as we intended, maybe we misunderstood the G52 definition:
> > >  
> > > But you didn't state the starting conditions or the final result.  But I'll assume all offsets were zero from the start:
> > >  
> > > Assume: Interpreter coords(DRO)  0 +  Offset 0  = Machine Coords 0
> > >  
> > > G0 Z-1.0 => Z DRO reads -1.0
> > >     This should cause a physical motion of -1 inches and the result will now be    Interpreter coords  -1  +  Offset 0  = Machine Coords -1
> > >  
> > >     Interpreter coords  0  +  Offset -1  = Machine Coords -1
> > >  
> > > G0 Z-1.0 => Z DRO reads -1.0
> > >     This should cause a physical motion of -1 inches and the result will now be
> > >  
> > > G52 Z-1.0 => Z DRO SHOULD change to 0.0, but it remains at -1.0
> > >     This forces the offset to -1 but it is aleady so changes nothing
> > >  
> > > G52 Z0.0 => Z DRO should return to -1.0 (what happened??)
> > >     Forcing the offset to zero should make DRO match Machine coordinates -2
> > >     Interpreter coords  -2  +  Offset 0  = Machine Coords -2
> > > Regards
> > > TK
> > >  
> > >  
> > >
> > > From: himykabibble <jagboy@>
> > > To: DynoMotion@yahoogroups.com
> > > Sent: Monday, November 14, 2011 9:19 AM
> > > Subject: [DynoMotion] Re: v428x & G52
> > >
> > >
> > >  
> > > Hmmmm.... After trying it, I think it's not... If I do the following:
> > >
> > > G0 Z-1.0 => Z DRO reads -1.0
> > > G92 Z0 => Z DRO reads 0.0
> > > G0 Z-1.0 => Z DRO reads -1.0
> > > G52 Z-1.0 => Z DRO SHOULD change to 0.0, but it remains at -1.0
> > > G52 Z0.0 => Z DRO should return to -1.0
> > >
> > > Regards,
> > > Ray L.
> > >
> > > --- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@> wrote:
> > > >
> > > > Tom,
> > > >
> > > > I see you've at least started adding G52 in v428x. Is that working properly, as far as you know?
> > > >
> > > > Regards,
> > > > Ray L.
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >      Interpreter coords  -1  +  Offset -1  = Machine Coords -2 G92 Z0 => Z DRO reads 0.0
> > >     Computes offset of -1 so that Machine remains the same with DRO 0
> > >
> >
> >
> >
> >
> >
> > To offset the current point by a given positive or negative distance (without motion), program
> >  G52 X~ Y~ Z~ A~ B~ C~, where the axis words contain the offsets you want to provide. All axis words are optional, except that at least one must be used. If an axis word is not used for a given axis, the coordinate on that axis of the current point is not changed. It is an error if:
> > ¨    all axis words are omitted.
> > G52 and G92 use common internal mechanisms in Mach3 and may not be used together.
> > When G52 is executed, the origin of the currently active coordinate system moves by the values given.
> > The effect of G52 is cancelled by programming G52 X0 Y0etc.
> > Here is an example. Suppose the current point is at X=4 in the currently specified coordinate system, then G52 X7sets the X-axis offset to 7, and so causes the X-coordinate of the current point to be -3.
> > The axis offsets are always used when motion is specified in absolute distance mode using any of the fixture coordinate systems.  Thus all fixture coordinate systems are affected by G52.
> >
>
Group: DynoMotion Message: 2246 From: himykabibble Date: 11/14/2011
Subject: Re: v428x & G52
Tom,

OK, what I've heard from people I trust, says you're right, and what I've done in the past worked largely by dumb luck, perhaps with a little help from bugs in Mach3 (the G92 and G52 code in Mach3 is known to have a number of problems). I also now have the Fanuc Programmers manual. If you want it as a reference, let me know. G92 is apparently considered largely obsolete, and the preferred operation is to use G10L2, G54-59, and G52. And there is apparently wide variation in the interpretation of the behavior of these modes in different controllers.

Regards,
Ray L.

--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> Hi Ray,
>  
> Yes I just tried Mach3 and it works like those references I sent.  In fact you can look on the Diagnostics screen and see there is only one offset G92 and it changes when you do G52.
>  
> Regards
> TK
>
> From: himykabibble <jagboy@...>
> To: DynoMotion@yahoogroups.com
> Sent: Monday, November 14, 2011 7:39 PM
> Subject: [DynoMotion] Re: v428x & G52
>
>
>  
> Tom,
>
> Like I said, I'm no expert, but Mach3 (current version, and at least several previous versions) work as I outlined. I'm going to ping some G-code experts I know, and see what they have to say. I have an old version of Mach3 that works, near as I can tell, like KMotionCNC is now working, so I'm more confused than ever at this point.
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> >
> > Hi Ray,
> >  
> > Well that is the issue.  I'm assuming that G92 and G52 are supposed affect the *same* offset (referred to a Axis Offsets in the source code). 
> >  
> > I looked up a reference of how EMC handles it and that's what it said. 
> >  
> > Also here is a reference from tormach which I thought was Mach3 based.
> >  
> > http://www.tormach.com/g52.html
> >  
> >  
> > And here is the Mach3 on-line help
> >  
> > G52 Coordinate System Offset
> > I haven't tried it in Mach3 though :}
> >  
> > TK
> >  
> >
> > From: himykabibble <jagboy@>
> > To: DynoMotion@yahoogroups.com
> > Sent: Monday, November 14, 2011 5:59 PM
> > Subject: [DynoMotion] Re: v428x & G52
> >
> >
> >  
> > Tom,
> >
> > First, I am no expert on this, but I do know how G92 and G52 work in Mach3, which is, in theory, consistent with the Fanuc implementation, and with the explanations in Peter Smid's book. Based on that, I believe both G92 and G52 are broken in v428x (at least - I never checked the G92 behavior in v426). Here is one sequence that I believe is wrong:
> >
> > First, I won't spell it out each time, but let's assume we always start these examples by doing a G52 Z0.0, then homing, so when we execute each block of code below, we start with work zero == machine zero, and G52 and G92 offsets are all zero. Then do:
> >
> > G92 Z2.0 => Z DRO should show +2.0
> > G52 Z0.0 => This should have no effect, but it sets Z DRO to 0.0, REMOVING the G92 offset.
> >
> > The G52, should do nothing, since we started by clearing the G52 offset before homing the machine. But, what it appears to be doing is clearing the G92 offset!
> >
> > Here's another example:
> >
> > G52 Z-1.0 => Z DRO should show +1.0
> > G92 Z0.0 => Z DRO should show 0.0
> > G52 Z0.0 => Z DRO should show -1.0, but instead remains at 0.0
> >
> > Here's a final example:
> >
> > G92 Z2.0 => Z DRO should show +2.0
> > G52 Z-0.5 => Z DRO should show +2.5
> > G52 Z0.0 => Z DRO should show +2.0
> >
> > Here is my understanding of how it should be:
> >
> > G92 is used to tell the controller what work coordinates you WANT the current position to be. The controller calculates the necessary G92 offset to apply, to make the work coordinates what you asked for. So, for example: G92 Z0.0, will always make the current Z axis position 0.000.
> >
> > G52 applies a temporary *additional* offset, which is expressed as a relative offset from any existing G92 offset. So, for example, if I do a G52 Z-1.0, the Z DRO should shift from its current value by +1.0. I find the easiest way to think of this is in terms of what happens to the axis work zero position. G52 Z-1.0 says: Shift the Z axis work zero DOWN by 1". So, if we were at Z=0.0 before the G52, we'll be at Z+1.0 after a G52 Z-1.0. If I now want to return to where I was, I simply execute a G52 Z0.0, and I return to the pre-existing G92 offsets.
> >
> > The G92 and G52 offsets are additive, but separate.
> >
> > It appears to me that when I do a G52 with KMotionCNC, it is clobbering the G92 offsets, which is wrong. G52 Z0.0 should remove ONLY the offset, if any, that was applied with another G52, without affecting any offset that was applied with G92. If no G52 offset is in effect, then G52 Z0.0 should have no effect whatsoever. In fact, when you use G52, it is good practice to start any program by zeroing the G52 offsets for all axes, in case an offset was left in effect from a previous run.
> >
> > At least that's my understanding, and how I've always used it with Mach3....
> >
> > Regards,
> > Ray L.
> >
> > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > >
> > > Hi Ray,
> > >  
> > > That is doing as we intended, maybe we misunderstood the G52 definition:
> > >  
> > > But you didn't state the starting conditions or the final result.  But I'll assume all offsets were zero from the start:
> > >  
> > > Assume: Interpreter coords(DRO)  0 +  Offset 0  = Machine Coords 0
> > >  
> > > G0 Z-1.0 => Z DRO reads -1.0
> > >     This should cause a physical motion of -1 inches and the result will now be    Interpreter coords  -1  +  Offset 0  = Machine Coords -1
> > >  
> > >     Interpreter coords  0  +  Offset -1  = Machine Coords -1
> > >  
> > > G0 Z-1.0 => Z DRO reads -1.0
> > >     This should cause a physical motion of -1 inches and the result will now be
> > >  
> > > G52 Z-1.0 => Z DRO SHOULD change to 0.0, but it remains at -1.0
> > >     This forces the offset to -1 but it is aleady so changes nothing
> > >  
> > > G52 Z0.0 => Z DRO should return to -1.0 (what happened??)
> > >     Forcing the offset to zero should make DRO match Machine coordinates -2
> > >     Interpreter coords  -2  +  Offset 0  = Machine Coords -2
> > > Regards
> > > TK
> > >  
> > >  
> > >
> > > From: himykabibble <jagboy@>
> > > To: DynoMotion@yahoogroups.com
> > > Sent: Monday, November 14, 2011 9:19 AM
> > > Subject: [DynoMotion] Re: v428x & G52
> > >
> > >
> > >  
> > > Hmmmm.... After trying it, I think it's not... If I do the following:
> > >
> > > G0 Z-1.0 => Z DRO reads -1.0
> > > G92 Z0 => Z DRO reads 0.0
> > > G0 Z-1.0 => Z DRO reads -1.0
> > > G52 Z-1.0 => Z DRO SHOULD change to 0.0, but it remains at -1.0
> > > G52 Z0.0 => Z DRO should return to -1.0
> > >
> > > Regards,
> > > Ray L.
> > >
> > > --- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@> wrote:
> > > >
> > > > Tom,
> > > >
> > > > I see you've at least started adding G52 in v428x. Is that working properly, as far as you know?
> > > >
> > > > Regards,
> > > > Ray L.
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >      Interpreter coords  -1  +  Offset -1  = Machine Coords -2 G92 Z0 => Z DRO reads 0.0
> > >     Computes offset of -1 so that Machine remains the same with DRO 0
> > >
> >
> >
> >
> >
> >
> > To offset the current point by a given positive or negative distance (without motion), program
> >  G52 X~ Y~ Z~ A~ B~ C~, where the axis words contain the offsets you want to provide. All axis words are optional, except that at least one must be used. If an axis word is not used for a given axis, the coordinate on that axis of the current point is not changed. It is an error if:
> > ¨    all axis words are omitted.
> > G52 and G92 use common internal mechanisms in Mach3 and may not be used together.
> > When G52 is executed, the origin of the currently active coordinate system moves by the values given.
> > The effect of G52 is cancelled by programming G52 X0 Y0etc.
> > Here is an example. Suppose the current point is at X=4 in the currently specified coordinate system, then G52 X7sets the X-axis offset to 7, and so causes the X-coordinate of the current point to be -3.
> > The axis offsets are always used when motion is specified in absolute distance mode using any of the fixture coordinate systems.  Thus all fixture coordinate systems are affected by G52.
> >
>
Group: DynoMotion Message: 2291 From: himykabibble Date: 11/17/2011
Subject: Re: v428x & G52
Tom,

Now that you've added communications between the DSP and the PC app, it would be helpful if you added a few more things. In particular, it would be helpful to have the Cnts/Inch data from KMotionCNC, so M-codes could pass real-world dimensions as arguments to DSP programs that use the Move functions to perform the moves. As an example, I have a wide range of probing functions as Mach3 macros, for doing things like locating edges, corners, the middle point between two edges, the center of a pocket or projection, aligning a vise, etc. I'd like to move those into DSP functions under KMotionCNC, but they all require knowing the steps/inch for the axes to generate the correct Move arguments.

Quote a few of the new functions have already come in very handy, and I have plans for the rest!

Regards,
Ray L.
Group: DynoMotion Message: 2325 From: Tom Kerekes Date: 11/18/2011
Subject: Re: v428x & G52
Hi Ray,
 
I added a command for KFLOP to request the resolutions of all 6 axis called:
 
// Requests the resolution in counts/inch for all 6 Axes as 32-bit floating point numbers
#define
 PC_COMM_GETAXISRES 19 // Persist+1 is which where to place them in the UserData vars.
 
 
Here is the patched KMotionCNC.exe:
 
 
Here are the modified source files:
 
 
 
 
I didn't test it :}
 
Thanks
TK

Group: DynoMotion Message: 2330 From: himykabibble Date: 11/18/2011
Subject: Re: v428x & G52
Tom,

I must be doing something wrong.... Here's what I did:

DoPC(PC_COMM_GETAXISRES);
printf("XRes=%f\n", *(float *)&persist.UserData[PC_COMM_PERSIST+1]);
printf("YRes=%f\n", *(float *)&persist.UserData[PC_COMM_PERSIST+2]);
printf("ZRes=%f\n", *(float *)&persist.UserData[PC_COMM_PERSIST+3]);
printf("ARes=%f\n", *(float *)&persist.UserData[PC_COMM_PERSIST+4]);

It prints all fields as 0's.

Regards,
Ray L.


--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> Hi Ray,
>  
> I added a command for KFLOP to request the resolutions of all 6 axis called:
>  // Requests the resolution in counts/inch for all 6 Axes as 32-bit floating point numbers#define
>  
>  
> Here is the patched KMotionCNC.exe:
>  
> http://dynomotion.com/Software/Patch/KMotionCNC.exe
>  
> Here are the modified source files:
>  
> http://dynomotion.com/Software/Patch/KMotionCNCDlg.cpp
>  
> http://dynomotion.com/Software/Patch/PC-DSP.h
>  
>  
> I didn't test it :}
>  
> Thanks
> TKPC_COMM_GETAXISRES 19 // Persist+1 is which where to place them in the UserData vars.
>
> From: himykabibble <jagboy@...>
> To: DynoMotion@yahoogroups.com
> Sent: Thursday, November 17, 2011 8:07 PM
> Subject: [DynoMotion] Re: v428x & G52
>
>
>  
> Tom,
>
> Now that you've added communications between the DSP and the PC app, it would be helpful if you added a few more things. In particular, it would be helpful to have the Cnts/Inch data from KMotionCNC, so M-codes could pass real-world dimensions as arguments to DSP programs that use the Move functions to perform the moves. As an example, I have a wide range of probing functions as Mach3 macros, for doing things like locating edges, corners, the middle point between two edges, the center of a pocket or projection, aligning a vise, etc. I'd like to move those into DSP functions under KMotionCNC, but they all require knowing the steps/inch for the axes to generate the correct Move arguments.
>
> Quote a few of the new functions have already come in very handy, and I have plans for the rest!
>
> Regards,
> Ray L.
>
Group: DynoMotion Message: 2331 From: Tom Kerekes Date: 11/18/2011
Subject: Re: v428x & G52
Hi Ray,
 
That command expects a parameter that specifies where KMotionCNC is supposed to put the 6 values
 
TK

Group: DynoMotion Message: 2333 From: himykabibble Date: 11/18/2011
Subject: Re: v428x & G52
Tom,

So.... DoPCInt(PC_COMM_GETAXISRES, 150); ??

Regards,
Ray L.

--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> Hi Ray,
>  
> That command expects a parameter that specifies where KMotionCNC is supposed to put the 6 values
>  
> TK
>
> From: himykabibble <jagboy@...>
> To: DynoMotion@yahoogroups.com
> Sent: Friday, November 18, 2011 9:51 PM
> Subject: [DynoMotion] Re: v428x & G52
>
>
>  
> Tom,
>
> I must be doing something wrong.... Here's what I did:
>
> DoPC(PC_COMM_GETAXISRES);
> printf("XRes=%f\n", *(float *)&persist.UserData[PC_COMM_PERSIST+1]);
> printf("YRes=%f\n", *(float *)&persist.UserData[PC_COMM_PERSIST+2]);
> printf("ZRes=%f\n", *(float *)&persist.UserData[PC_COMM_PERSIST+3]);
> printf("ARes=%f\n", *(float *)&persist.UserData[PC_COMM_PERSIST+4]);
>
> It prints all fields as 0's.
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> >
> > Hi Ray,
> >  
> > I added a command for KFLOP to request the resolutions of all 6 axis called:
> >  // Requests the resolution in counts/inch for all 6 Axes as 32-bit floating point numbers#define
> >  
> >  
> > Here is the patched KMotionCNC.exe:
> >  
> > http://dynomotion.com/Software/Patch/KMotionCNC.exe
> >  
> > Here are the modified source files:
> >  
> > http://dynomotion.com/Software/Patch/KMotionCNCDlg.cpp
> >  
> > http://dynomotion.com/Software/Patch/PC-DSP.h
> >  
> >  
> > I didn't test it :}
> >  
> > Thanks
> > TKPC_COMM_GETAXISRES 19 // Persist+1 is which where to place them in the UserData vars.
> >
> > From: himykabibble <jagboy@>
> > To: DynoMotion@yahoogroups.com
> > Sent: Thursday, November 17, 2011 8:07 PM
> > Subject: [DynoMotion] Re: v428x & G52
> >
> >
> >  
> > Tom,
> >
> > Now that you've added communications between the DSP and the PC app, it would be helpful if you added a few more things. In particular, it would be helpful to have the Cnts/Inch data from KMotionCNC, so M-codes could pass real-world dimensions as arguments to DSP programs that use the Move functions to perform the moves. As an example, I have a wide range of probing functions as Mach3 macros, for doing things like locating edges, corners, the middle point between two edges, the center of a pocket or projection, aligning a vise, etc. I'd like to move those into DSP functions under KMotionCNC, but they all require knowing the steps/inch for the axes to generate the correct Move arguments.
> >
> > Quote a few of the new functions have already come in very handy, and I have plans for the rest!
> >
> > Regards,
> > Ray L.
> >
>
Group: DynoMotion Message: 2337 From: Tom Kerekes Date: 11/18/2011
Subject: Re: v428x & G52
correct

Group: DynoMotion Message: 2340 From: himykabibble Date: 11/19/2011
Subject: Re: v428x & G52
Tom,

Still doesn't seem to work - it shows all zeroes. Here's the code I'm running, using the exe you posted:

DoPCInt(PC_COMM_GETAXISRES, 150);
printf("XRes=%f\n", *(float *)&persist.UserData[151]);
printf("YRes=%f\n", *(float *)&persist.UserData[152]);
printf("ZRes=%f\n", *(float *)&persist.UserData[153]);
printf("ARes=%f\n", *(float *)&persist.UserData[154]);

Regards,
Ray L.

--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> correct
>
>
> From: himykabibble <jagboy@...>
> To: DynoMotion@yahoogroups.com
> Sent: Friday, November 18, 2011 10:07 PM
> Subject: [DynoMotion] Re: v428x & G52
>
>
>  
> Tom,
>
> So.... DoPCInt(PC_COMM_GETAXISRES, 150); ??
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> >
> > Hi Ray,
> >  
> > That command expects a parameter that specifies where KMotionCNC is supposed to put the 6 values
> >  
> > TK
> >
> > From: himykabibble <jagboy@>
> > To: DynoMotion@yahoogroups.com
> > Sent: Friday, November 18, 2011 9:51 PM
> > Subject: [DynoMotion] Re: v428x & G52
> >
> >
> >  
> > Tom,
> >
> > I must be doing something wrong.... Here's what I did:
> >
> > DoPC(PC_COMM_GETAXISRES);
> > printf("XRes=%f\n", *(float *)&persist.UserData[PC_COMM_PERSIST+1]);
> > printf("YRes=%f\n", *(float *)&persist.UserData[PC_COMM_PERSIST+2]);
> > printf("ZRes=%f\n", *(float *)&persist.UserData[PC_COMM_PERSIST+3]);
> > printf("ARes=%f\n", *(float *)&persist.UserData[PC_COMM_PERSIST+4]);
> >
> > It prints all fields as 0's.
> >
> > Regards,
> > Ray L.
> >
> > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > >
> > > Hi Ray,
> > >  
> > > I added a command for KFLOP to request the resolutions of all 6 axis called:
> > >  // Requests the resolution in counts/inch for all 6 Axes as 32-bit floating point numbers#define
> > >  
> > >  
> > > Here is the patched KMotionCNC.exe:
> > >  
> > > http://dynomotion.com/Software/Patch/KMotionCNC.exe
> > >  
> > > Here are the modified source files:
> > >  
> > > http://dynomotion.com/Software/Patch/KMotionCNCDlg.cpp
> > >  
> > > http://dynomotion.com/Software/Patch/PC-DSP.h
> > >  
> > >  
> > > I didn't test it :}
> > >  
> > > Thanks
> > > TKPC_COMM_GETAXISRES 19 // Persist+1 is which where to place them in the UserData vars.
> > >
> > > From: himykabibble <jagboy@>
> > > To: DynoMotion@yahoogroups.com
> > > Sent: Thursday, November 17, 2011 8:07 PM
> > > Subject: [DynoMotion] Re: v428x & G52
> > >
> > >
> > >  
> > > Tom,
> > >
> > > Now that you've added communications between the DSP and the PC app, it would be helpful if you added a few more things. In particular, it would be helpful to have the Cnts/Inch data from KMotionCNC, so M-codes could pass real-world dimensions as arguments to DSP programs that use the Move functions to perform the moves. As an example, I have a wide range of probing functions as Mach3 macros, for doing things like locating edges, corners, the middle point between two edges, the center of a pocket or projection, aligning a vise, etc. I'd like to move those into DSP functions under KMotionCNC, but they all require knowing the steps/inch for the axes to generate the correct Move arguments.
> > >
> > > Quote a few of the new functions have already come in very handy, and I have plans for the rest!
> > >
> > > Regards,
> > > Ray L.
> > >
> >
>
Group: DynoMotion Message: 2342 From: Tom Kerekes Date: 11/19/2011
Subject: Re: v428x & G52
Hi Ray,
 
Yes there was a bug (I was casting a double instead of a float).
 
Overwrote the files .exe and source.
 
Regards
TK

Group: DynoMotion Message: 2343 From: himykabibble Date: 11/19/2011
Subject: Re: v428x & G52
Tom,

That's better!

Regards,
Ray L.

--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> Hi Ray,
>  
> Yes there was a bug (I was casting a double instead of a float).
>  
> Overwrote the files .exe and source.
>  
> Regards
> TK
>
> From: himykabibble <jagboy@...>
> To: DynoMotion@yahoogroups.com
> Sent: Saturday, November 19, 2011 7:12 AM
> Subject: [DynoMotion] Re: v428x & G52
>
>
>  
> Tom,
>
> Still doesn't seem to work - it shows all zeroes. Here's the code I'm running, using the exe you posted:
>
> DoPCInt(PC_COMM_GETAXISRES, 150);
> printf("XRes=%f\n", *(float *)&persist.UserData[151]);
> printf("YRes=%f\n", *(float *)&persist.UserData[152]);
> printf("ZRes=%f\n", *(float *)&persist.UserData[153]);
> printf("ARes=%f\n", *(float *)&persist.UserData[154]);
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> >
> > correct
> >
> >
> > From: himykabibble <jagboy@>
> > To: DynoMotion@yahoogroups.com
> > Sent: Friday, November 18, 2011 10:07 PM
> > Subject: [DynoMotion] Re: v428x & G52
> >
> >
> >  
> > Tom,
> >
> > So.... DoPCInt(PC_COMM_GETAXISRES, 150); ??
> >
> > Regards,
> > Ray L.
> >
> > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > >
> > > Hi Ray,
> > >  
> > > That command expects a parameter that specifies where KMotionCNC is supposed to put the 6 values
> > >  
> > > TK
> > >
> > > From: himykabibble <jagboy@>
> > > To: DynoMotion@yahoogroups.com
> > > Sent: Friday, November 18, 2011 9:51 PM
> > > Subject: [DynoMotion] Re: v428x & G52
> > >
> > >
> > >  
> > > Tom,
> > >
> > > I must be doing something wrong.... Here's what I did:
> > >
> > > DoPC(PC_COMM_GETAXISRES);
> > > printf("XRes=%f\n", *(float *)&persist.UserData[PC_COMM_PERSIST+1]);
> > > printf("YRes=%f\n", *(float *)&persist.UserData[PC_COMM_PERSIST+2]);
> > > printf("ZRes=%f\n", *(float *)&persist.UserData[PC_COMM_PERSIST+3]);
> > > printf("ARes=%f\n", *(float *)&persist.UserData[PC_COMM_PERSIST+4]);
> > >
> > > It prints all fields as 0's.
> > >
> > > Regards,
> > > Ray L.
> > >
> > > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > >
> > > > Hi Ray,
> > > > ÃÆ'‚ 
> > > > I added a command for KFLOP to request the resolutions of all 6 axis called:
> > > > ÃÆ'‚ // Requests the resolution in counts/inch for all 6 Axes as 32-bit floating point numbers#define
> > > > ÃÆ'‚ 
> > > > ÃÆ'‚ 
> > > > Here is the patched KMotionCNC.exe:
> > > > ÃÆ'‚ 
> > > > http://dynomotion.com/Software/Patch/KMotionCNC.exe
> > > > ÃÆ'‚ 
> > > > HereÃÆ'‚ are the modified source files:
> > > > ÃÆ'‚ 
> > > > http://dynomotion.com/Software/Patch/KMotionCNCDlg.cpp
> > > > ÃÆ'‚ 
> > > > http://dynomotion.com/Software/Patch/PC-DSP.h
> > > > ÃÆ'‚ 
> > > > ÃÆ'‚ 
> > > > I didn't test it :}
> > > > ÃÆ'‚ 
> > > > Thanks
> > > > TKPC_COMM_GETAXISRES 19 // Persist+1 is which where to place them in the UserData vars.
> > > >
> > > > From: himykabibble <jagboy@>
> > > > To: DynoMotion@yahoogroups.com
> > > > Sent: Thursday, November 17, 2011 8:07 PM
> > > > Subject: [DynoMotion] Re: v428x & G52
> > > >
> > > >
> > > > ÃÆ'‚ 
> > > > Tom,
> > > >
> > > > Now that you've added communications between the DSP and the PC app, it would be helpful if you added a few more things. In particular, it would be helpful to have the Cnts/Inch data from KMotionCNC, so M-codes could pass real-world dimensions as arguments to DSP programs that use the Move functions to perform the moves. As an example, I have a wide range of probing functions as Mach3 macros, for doing things like locating edges, corners, the middle point between two edges, the center of a pocket or projection, aligning a vise, etc. I'd like to move those into DSP functions under KMotionCNC, but they all require knowing the steps/inch for the axes to generate the correct Move arguments.
> > > >
> > > > Quote a few of the new functions have already come in very handy, and I have plans for the rest!
> > > >
> > > > Regards,
> > > > Ray L.
> > > >
> > >
> >
>